Міністерство освіти і науки України Національний університет „Львівська політехніка” Кафедра ЕОМ Звіт з лабораторної роботи №2 з дисципліни “ Тестування програмних засобів ”  Львів 2012 Мета: розглянути фреймворки для автоматизованого тестування програмного забезпечення. Виконання роботи: Фреймворк SoapUI Soap UI - веб-сервіс з відкритим кодом, призначений для тестування додатків з сервіс-орієнтованою архітектурою (SOA). Його функціональність включає перевірку, розробку, симуляцію, виклик і фальшивий викли веб-сервісу, функціональні, завантажувальні і піддатливе тестування веб-сервісу. Комерційна версія soapUI Pro, взагальному фокусується на досягненні продуктивності і розроблена сторонніми компаніями.
Рис. 1 Головне вікно Soap UI Перший реліз Soap UI був завантажений на Sourceforge в листопаді 2005. Це ПЗ з відкритим кодом випущене з ліцензією GNU/GPL. Цей фреймворк було завантажено більш ніж 2000000 разів з часу першого релізу. Він побудований на платформі Java і використовує Swing для інтерфейсу користувача, тому він є кросплатформенним. Сьогодні він підтримує IDEA, Eclipse i NetBeans. Він підтримує такі можливості: Перевірка веб-сервісів Запуск веб-сервівсів Розробку веб-сервівсів Емуляцію роботи веб-сервівсів і Функціонал завантаження і тестування безпеки веб-сервісу Одна з основних проблем, які виникають під час інтеграції різних систем між собою це те, що на момент розробки ці сервіси або не існують, або не завжди доступні (або доступні з великими проблемами). Таке може статися, якщо, наприклад, компанія розробляє додаток на базі SOA, і кожен з сервісів створюється паралельно різними людьми. Чекати поки одна людина закінчить свій компонент, перш ніж приступати до своєї розробці - не найефективніший спосіб. Добре, якщо всі сервіси знаходяться в руках однієї компанії, тоді можна ще хоч якось домовитися, але в реальності все буває якраз навпаки - сервіси знаходяться під контролем сторонніх компаній і буває дуже складно вплинути на їх розробку. Щоб це було легше зрозуміти - уявімо гіпотетичну ситуацію. Існує якась компанія, яка займається виконання різного роду технічних робіт, наприклад ремонтує / контролює / встановлює охоронні системи. У компанії є регістр даних клієнтів, що зберігається в якійсь базі даних. Доступ до цієї бази даних можна отримати через спеціальний інтерфейс, через який дані про клієнтів заносяться в систему, проглядаються і оновлюються. Коли приходить новий замовлення, то він оформляється у ще одній спеціальній системі замовлень, після чого на об'єкт відправляється технік, який власне і займається обслуговуванням охоронних систем. У техніка є загальна інструкція, що описує, як він має діяти на об'єкт, але, в принципі, кожен з них діє за власним розсудом, виходячи з ситуації на місці. Після виконання роботи - технік створює звіт у вільній формі, який зберігається в певної третьої системі. Припустимо, що компанія хоче покращити якість звітів. Вона хоче бачити, які саме роботи були зроблені, скільки часу займала кожна з них, які проблеми найбільш часті і так далі. Всю цю інформацію планується використовувати для поліпшення продуктивності і, як результат, зниження витрат і збільшення обороту. Для цього планується впровадити нову інформаційну систему, яка дозволить стандартизувати робочий процес. Виглядає це як список завдань / checklist на PDA техніка, які він повинен виконати, відвідавши об'єкт. Ця ж система дозволить пакувати замовлення таким чином, щоб одному техніку діставалися замовлення в одній і тій же частині міста, тим самим збільшивши кількість об'єктів, які він може відвідати за день. Наймати працівника в штат компанія не бажає і тому наймається контрактор, який, власне, і інтегрує ці системи між собою. Ось тут починається саме інтересaное. Як правило, бази даних, що зберігають клієнтів, замовлення, звіти, доступні усередині корпоративної мережі, але не видно зовні з причин безпеки. У той же час, навіть перебуваючи всередині мережі, доступ можна отримати тільки прямо приєднати до ...